Should this also cover exclusiveMinimum and exclusiveMaximum? Also note that those fields have different representations between OAS 3.0 and OAS 3.1, where 3.0 is a boolean while 3.1. allows for a value (so for OAS 3.1 it might be that minimum is entirely omitted and that only exclusiveMinimum is specificed).

Do note that it might be that the project represent them the same internally, as they do for some OAS 3.1 concepts.

Should this also cover exclusiveMinimum and exclusiveMaximum? Also note that those fields have different representations between OAS 3.0 and OAS 3.1, where 3.0 is a boolean while 3.1. allows for a value (so for OAS 3.1 it might be that minimum is entirely omitted and that only exclusiveMinimum is specificed).

Do note that it might be that the project represent them the same internally, as they do for some OAS 3.1 concepts.

Hmm, good point. I would expect that such things should be ideally already handled by the normalizer? Or is it problematic because the values are not integers?

But thanks for raising this. I see my blind attempt to centralize the logic in the ModelUtils.resolveMaximum and ModelUtils.resolveMinimum might be a bit premature. As I was considering it mostly in the context of the page/size use. That was definitely short-sighted.

I am unable to provide comments in code, since I get an external error (so might be that you are flooded with the same comment over and over later).

What I am wondering is if schema.getAllOf() != null can be done with the utils function hasAllOf.

I would also suggest that some shared concepts be broken out into methods to improve readability and reduce duplication. For example that

if (schema == null) return null;
if (schema.get$ref() != null) {
    schema = getReferencedSchema(openAPI, schema);
    if (schema == null) return null;
}

Is broken out into a "getRefSchema()" (might be that it already exists?). In the same vein also maybe the same for the if-cases.

E.g.,
resolved != null && resolved.getMinimum() != null to hasMinimum
and
result == null || resolved.getMinimum().compareTo(result) > 0 to stricterMinimum.

This would change the code from "null, null, ..., null" to
"If there is a schema (referenced or direct), that has one or more allOfs. Then go through all allOfs and take the minimum value if there is one. Keep the most strict value".

Heavily opinionated of course and goes against how everything else is done. But personally I find most of the code to be extremely hard to read when it really should not be give the trivial things that are done.

Should this also cover exclusiveMinimum and exclusiveMaximum? Also note that those fields have different representations between OAS 3.0 and OAS 3.1, where 3.0 is a boolean while 3.1. allows for a value (so for OAS 3.1 it might be that minimum is entirely omitted and that only exclusiveMinimum is specificed).
Do note that it might be that the project represent them the same internally, as they do for some OAS 3.1 concepts.

Hmm, good point. I would expect that such things should be ideally already handled by the normalizer? Or is it problematic because the values are not integers?

But thanks for raising this. I see my blind attempt to centralize the logic in the ModelUtils.resolveMaximum and ModelUtils.resolveMinimum might be a bit premature. As I was considering it mostly in the context of the page/size use. That was definitely short-sighted.

One could also reason that it is out-of-scope and that someone that utilizes exclusiveMaximum will have to extend your initial logic to support their use-case. I believe the current structure and separation of responsibility should make it at least semi-straightforward. And as always, if one aim to support everything with the first version, then one might never get a first version. 😄

No, I think this is a really good point. I will try to fix it. This might bite someone, when they decide to rely on the method later. It is called *Utils after all (-: